查看原文
其他

《一问一实验:AI 版》520 献给 DBA 们的 AI

ChatDBA 爱可生开源社区 2024-05-22


什么是《一问一实验》?

《一问一实验》是爱可生开源社区的王牌专栏。每一期通过一个数据库问题对应一组实验的形式,简明易懂地讲解数据库基础知识。自 2020 年连载至今已发布 50 期,全网累计阅读量超 50 万。受到行业读者们的一致好评!真正成为了 DBA 们爱读、好读的技术内容。

《一问一实验:AI 版》全新归来,在 520 这个充满爱的特殊日子里,献上一份属于 DBA 们的爱(AI)。

专栏作者采访

问题:为什么会断更这么久?

黄炎:冠冕堂皇地说,就是被其他更好玩的事情吸引了兴趣。大模型的突破 在技术生产力上提供了巨大的可能性,对这些可能性的探索占用了非常多的时间。

所幸我们找到了将 AI 和专栏合并发展的方式:我们在公司内部建立了 ChatDBA(给 DBA 用的智能辅助系统,负责辅助 DBA 进行故障诊断处理等工作)来协助日常工作;从第 51 期开始,专栏的主要作者更换成了 ChatDBA,并由人类专家对专栏质量进行点评。

问题:会给读者们带来什么新的体验?

黄炎:ChatDBA 使用了多种常见和不常见的技术(它不单纯是 LLM+RAG),这个复杂的结构主要想让 ChatDBA 脱离“搜索引擎”这个功能层次。在故障诊断处理中 能进行引导/指导、对知识的使用更精确、思考模式更“人化”。我们希望由 AI 续写的专栏跟人类专家写的专栏没有差异(包括技术逻辑的正确性, 知识内容的详略程度, "人化"程度等方面)。

不过,目前 ChatDBA 还处于初级阶段,不能立马达到我的预期。

问题:这次的 AI 版和之前的版本有什么区别?

黄炎:随着 ChatDBA 后续的迭代,专栏的内容会逐渐产生一些变化。比如:

  • 单纯的故障诊断 -> 深度的原理解析
  • 单纯的数据库级别的分析 -> 整合操作系统和网络等多方面知识
  • 单纯的事实推理 -> 技术猜想+验证
  • 单纯的解决问题 -> 形成工具
  • 短链推理 -> 长链推理
  • 现象推理 -> 源码解释
  • ……

这些变化都会依赖于大模型本身的逻辑能力提高(希望国内外的大模型公司推出技术逻辑性更强的模型),以及 ChatDBA 的架构进化。

希望在专栏中向大家提供更多好玩的知识。

下面让我们正式进入《一问一实验:AI 版》的第 51 期。

问题

在 MySQL 日志中发现有大量报错,可能是什么原因造成的?

报错信息:

2024-04-26 23:27:06 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_11' is full
2024-04-27 00:11:04 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_1' is full

实验

1. 将问题丢给 ChatDBA

有了 ChatDBA 加持,遇到问题就先别自己费劲了,扔给 ChatDBA 先看看它怎么说?

完整演示视频



左侧为流程分析画布,展示 ChatDBA 对此问题的排查逻辑;右侧为互动区域。

从左边的画布区域和右侧的对话区域可知,造成该问题的原因可能有以下几点:

  • 配置的临时表空间大小不足。
  • 数据库中执行的 SQL 查询创建了大量临时表。
  • 磁盘空间不足或资源限制。

接下来我们根据 ChatDBA 的推荐的执行步骤查看一下相关配置。

2. ChatDBA 协助问题排查

首先,根据推荐的步骤检查参数的配置情况如何。

接下来,把从系统中查询到的配置信息提供给 ChatDBA。

在这里,ChatDBA 意识到日志表满的报错可能与这个配置有关,但是还不能具体确定,所以希望我们提供对应的临时表实际使用情况。通过 ChatDBA 给出的两条命令执行后可知 MySQL 的临时表空间(ibtmp1)实际已经占用了 50G。

可以看到,ChatDBA 大概率已经确认是参数配置导致的,但是同时也指出长事务、长查询这些才有可能是问题的真正原因。

最后,ChatDBA 给出的解决方案首先是优化对应的 SQL 语句,但是在当前的业务场景下无法直接修改 SQL,所以我们选择通过修改参数的方式来临时处理。

3. ChatDBA 给出解决方案

ChatDBA 提供了扩展临时表空间的具体步骤,执行调整 innodb_temp_data_file_path 参数的配置。

4. 实验总结

针对 2024-04-26 23:27:06 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_11' is full 报错的问题,我们看到了三个排查方向:参数配置过小;磁盘空间不足;SQL语句创建了大量的临时表。

ChatDBA 给出的解决方向是先看配置情况(在我们日常工作中也可以参考这个 case 的排查思路),先用查询的方法拿到配置信息快速定位问题,然后通过调整参数的方法临时解决问题,最后才是深度追踪问题的根源。

在这个 case 中是因为用户的业务场景中有大量的长事务、长查询存在,所以导致对临时表空间占用很高,需要配合业务方针对性的优化 SQL 语句才是解决此问题的最终办法。

问问 ChatGPT-4o


我们也将相同的问题送给了 ChatGPT-4o,让我们看看效果如何。

可以看到这类通用的大语言模型偏好是给用户一个大而全的内容,但是缺少具体的操作指向性与问题理解能力,导致用户在输入信息后没有办法很好的确定下一步应该做什么,从而真正的解决问题。

什么是 ChatDBA?




继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存